Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[browser] js string marshaling by value #95180

Merged
merged 7 commits into from
Nov 29, 2023

Conversation

pavelsavara
Copy link
Member

@pavelsavara pavelsavara commented Nov 23, 2023

New MSbuild flag WasmJsInteropByValue which is false by default on ST build and true on MT build.

Make string marshaling by value rather than by reference to MonoString*

The motivation is that

  • Native AOT is not Mono
  • MT may need to marshal to unmanaged thread

This removes optimization we have for interned strings, when enabled.

I didn't fix it for legacy interop.

@pavelsavara pavelsavara added arch-wasm WebAssembly architecture area-System.Runtime.InteropServices.JavaScript os-browser Browser variant of arch-wasm labels Nov 23, 2023
@pavelsavara pavelsavara added this to the 9.0.0 milestone Nov 23, 2023
@pavelsavara pavelsavara self-assigned this Nov 23, 2023
@ghost
Copy link

ghost commented Nov 23, 2023

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Make string marshaling by value rather than by reference to MonoString*

The motivation is that

  • Native AOT is not Mono
  • MT may need to marshal to unmanaged thread
Author: pavelsavara
Assignees: pavelsavara
Labels:

arch-wasm, area-System.Runtime.InteropServices.JavaScript, os-browser

Milestone: 9.0.0

@pavelsavara pavelsavara changed the title [browser] Configurable string marshling by value [browser] js string marshling by value Nov 23, 2023
@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara pavelsavara changed the title [browser] js string marshling by value [browser] js string marshaling by value Nov 23, 2023
@pavelsavara pavelsavara marked this pull request as ready for review November 23, 2023 16:26
@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Member

@kg kg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand why we're doing this, but the code looks fine

src/mono/wasm/wasm.proj Outdated Show resolved Hide resolved
@pavelsavara pavelsavara force-pushed the browser_string_interop_by_value branch from c66f1b0 to 4a2bf17 Compare November 27, 2023 09:58
@pavelsavara
Copy link
Member Author

I'm not sure I understand why we're doing this

@kg

  • For NativeAOT sake - there is no Mono and MonoString* there.
  • for deputy MT experiment, dealing with MonoString requires we enter MONO_ENTER_GC_UNSAFE on UI thread, which could be blocking operation.

# Conflicts:
#	src/libraries/System.Runtime.InteropServices.JavaScript/src/System.Runtime.InteropServices.JavaScript.csproj
@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@@ -115,6 +116,8 @@
<WasmEnableExceptionHandling Condition="'$(WasmEnableExceptionHandling)' == ''">true</WasmEnableExceptionHandling>
<WasmEnableSIMD Condition="'$(WasmEnableSIMD)' == ''">$(WasmEnableExceptionHandling)</WasmEnableSIMD>
<WasmEnableLegacyJsInterop Condition="'$(WasmEnableLegacyJsInterop)' == ''">true</WasmEnableLegacyJsInterop>
<WasmEnableJsInteropByValue Condition="'$(WasmEnableJsInteropByValue)' == '' and ( '$(WasmEnableThreads)' == 'true' or '$(MonoWasmBuildVariant)' == 'multithread' )">true</WasmEnableJsInteropByValue>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't WasmEnableThreads user facing, and MonoWasmBuildVariant is meant more for the wasm/runtime build itself? I see that it is being used in a couple of other places, which we should fix too. Not necessary for this PR.

Copy link
Member Author

@pavelsavara pavelsavara Nov 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes it easy to work in-tree with samples and unit tests when you just have MonoWasmBuildVariant set globally and sometimes native rebuild kicks in. Maybe it could be unified somehow, I'm not 100% sure about it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can set WasmEnableThreads based on MonoWasmBuildVariant in WasmApp.InTree.targets.

Copy link
Member Author

@pavelsavara pavelsavara Nov 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer if you could help me to improve it in different PR. But I would like to ask details in meantime

what are you supposed to use WasmEnableThreads or MonoWasmBuildVariant inside of

  • wasm.proj
  • WasmApp.Native.targets
  • C code like drive.c triggered by
    • runtime build (wasm.proj)
    • external application native rebuild (WasmApp.Native.targets)
    • in-tree sample native rebuild (WasmApp.InTree.targets)
  • inside .csproj of libraries.
  • inside .csproj of libraries unit tests
  • inside .csproj of in-tree samples
  • in .csproj of WBT

What are you supposed to use WasmEnableThreads or MonoWasmBuildVariant on commandline ?

  • when you build runtime and libraries with build.sh
  • when you run unit tests. This could trigger re-build of C# libraries
  • when you run samples in-tree. This could trigger re-build of C# libraries

How does it propagate to the nested build/publish ?
Does build on helix changes anything about it ?
Does WBT runtime installation in artifacts changes anything about it ?
Is there really benefit of having 2 of them ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MonoWasmBuildVariant is really only for non-user projects, so wasm.proj would be an example.
All the other test cases (except WBT) use InTree targets, so adding overrides there would apply to all of them.
WBT strictly uses what the user gets, so no InTree targets.

Is there really benefit of having 2 of them ?

Not really. I think we had that before for multithread, and perftrace builds but now we don't need a string property. It is clearer to have them separate but I wouldn't mind using only WasmEnableThreads either.
What I do want to avoid is using internal build properties in user facing targets.

cc @lambdageek

@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara pavelsavara merged commit c089092 into dotnet:main Nov 29, 2023
133 of 135 checks passed
@pavelsavara pavelsavara deleted the browser_string_interop_by_value branch November 29, 2023 09:45
@github-actions github-actions bot locked and limited conversation to collaborators Dec 30, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-System.Runtime.InteropServices.JavaScript os-browser Browser variant of arch-wasm
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants